It is common for software or hardware in multi-tier systems to communicate with a back-end server during time critical transactions with an end user. For example, a network access server such as CiscoSecure Access Control Server (ACS) is able to perform user authentication and authorization against a number of third party back-end servers such as directory servers, relational database management system (RDBMS) servers, etc. In order to provide greater uptime and reliability, information technology (IT) and quality assurance teams associated with the manufacturer of these systems often attempt to verify that the hardware and software in these systems communicate effectively with the back-end servers.
However, verifying the reliability of communications systems can be difficult when the problem in communications between a client and a server is related to or caused by an overload and non-responsiveness of the back-end server, rather than network traffic. Most systems cannot provide a mechanism to test a product or reproduce a customer problem where the back-end server is overloaded, and consequently delays sending responses to the client. This may occur where a client's request successfully reaches the server host over the network, but the client request must wait in the server's queue until the server is available to handle the request. In this situation, the problem is not in the loading of the network, but rather in the loading of the server.
Network load simulators are commonly used for simulating an artificial load on a network. The network load simulator floods the network with artificial traffic that competes with the application traffic for network resources. It creates a bottleneck in the network for communications between the application client and application server. Thus, a network load simulator is well adapted and useful for testing the reliability of the server and evaluating the response of a network when the application server is unreachable as a network host.
However, the use of network load simulators has numerous disadvantages, particularly when testing the susceptibility of the client to delays in the response of the server. First, they are incapable of simulating a scenario where client request packets have successfully reached the server, but due to overloading or some other problem, the server is unable to provide a response. In that case, the network connection is established and maintained, so flooding the network with artificial traffic will not simulate this problem.
Second, if non-responsiveness of the server is caused by bugs in the client application or server application, flooding the network with artificial traffic will not reveal the source of the application bugs. For example, if the client makes a synchronous RPC call to the server but the server is unreachable, an error eventually is returned to the client. On the other hand, if the call successfully reaches the server but the server is overloaded, the server does not respond and the client receives no indication of an error. Flooding the network will not simulate this problem.
Third, it is difficult to reproduce a problem arising from server application loading with network load simulators, because they are difficult to fine-tune in order to simulate and reproduce the server delay.
Also, although some network load simulators can produce or replay application specific traffic and can be used to simulate the server load, there is undue special configuration and preparation work required to do it, and reproducing the exact server delay remains difficult.
Based on the foregoing, there is a clear need for a generic application server load simulator that allows the load of application servers to be simulated on the network without the need to create application specific clients. There is a specific need for a simulator that can simulate a scenario where client request packets reach the server, but the response is delayed as a result of load on the server rather than a bottleneck in the network.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.